With the continued development of more powerful client devices such as mobile phones and tablets, the architecture used for application development has begun to shift away from developing “thin” client applications with more complex server-side application back-ends. Instead, much software development is architected to utilizes more complex client applications. In particular, some of these “rich” client applications now rely upon remote servers (e.g., “the cloud”) primarily for accessing and storing data that is used by the client applications.
One way that client applications interact with remote data sources is through “web services.” Web services, at their core, are software-based systems that provide information between two electronic devices over a network. For example, a web service is typically a software component provided through a network-accessible endpoint that can be “called” from other applications. For example, an organization may implement a web service that provides up-to-the-minute weather data, stock prices, transit information, or any other type of information for consumers. The information provided by the web service may be retrieved by an application executing in a browser, by a stand-alone or native application executing on a computing device, or by other hardware and/or software components. A web service may have an interface described in a machine-processable format, such as Web Services Description Language (WSDL). Systems can interact with a web service in a manner prescribed by its description, for instance, using Simple Object Access protocol (SOAP) messages.
Two major classes of web services are commonly used: REST-compliant web services, in which the primary purpose of the service is to provide access to representations of resources using a uniform set of “stateless” operations, and arbitrary web services, in which the service may expose an arbitrary set of operations. REST, or REpresentational State Transfer, is a communications paradigm for distributed systems such as the World Wide Web. REST-style architectures include clients and servers, where clients send requests to the servers that in turn process these requests and return appropriate responses back to the clients. In REST systems, requests and responses are built around the transfer of representations of resources, which capture a current or intended state of the underlying resource. Information that can be named can be a “resource”: a document, image, a temporal service (e.g., “today's weather in Los Angeles”), a collection of other resources, a non-virtual object (e.g. a person), etc. REST components perform actions on a resource by using a representation to capture the current or intended state of that resource, and transferring that representation between components.
REST-based web services do not require XML (Extensible Markup Language), SOAP, or WSDL service API definitions. Instead, REST-based web services often constrain their interfaces to a small set of well-known, standard operations (e.g., GET, POST, PUT, and DELETE for use with HTTP interactions). REST-based web services interact with stateful resources as opposed to having stateful messages and operations.
Web service APIs (Application Programming Interfaces) that adhere to the architectural constraints of REST are called RESTful. HTTP-based RESTful APIs may be defined using a base URI for a resource, an Internet media type for the data (e.g., JSON, XML, Atom, etc.), HTTP methods (e.g., GET, PUT, POST, DELETE), hypertext links to reference state, and/or hypertext links to reference related resources. One way to define a created RESTful API is using the RESTful API Modeling Language (RAML), which provides all the information necessary to describe RESTful or practically-RESTful APIs. Software developers may, using such an API definition, build client applications that “consume” resources provided by a RESTful web service.